IBIS Macromodel Task Group Meeting date: 02 July 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma Ken Willis Intel: Michael Mirmak Keysight Technologies: Fangyi Rao Radek Biernacki Ming Yan Stephen Slater Maziar Farahmand Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz * Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Arpad to submit BIRD197.3 to the Open Forum per Bob's motion. - Done. BIRD197.3 was introduced at the Open Forum meeting on June 28, 2019. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the June 18 meeting. Randy moved to approve the minutes. Walter seconded the motion. There were no objections. ------------- New Discussion: BIRD197.3 (DC_Offset and NRZ_Threshold): Arpad noted that he had two issues with the newly submitted BIRD that might need discussion. The first was a comment from Randy captured in the previous meeting's minutes: "Randy noted that we are not really defining what to do. He said it's convenient if the tool adds the DC_Offset back in for display of the waveform, but if the model has returned a waveform that already contains the offset this could be a problem. By not defining things, we may end up with inconsistencies in the way various tools display the same output waveform." The second issue was with this statement in the "Definition" of DC_Offset: "The mean value of the steady state high and low voltages of the channel at the Rx pad." Arpad had sent an email to ATM about the interpretation of this statement, and felt it might need further discussion. Arpad opened discussion by asking Randy if he thought his concern from the previous meeting had been adequately addressed. Randy said he wasn't sure there was something we should do about it. He noted that it may be up to tools to decide if they want to provide a way to shift the waveform. He noted that a tool probably can't do it automatically if it doesn't know what's coming out of the Rx. Arpad again pointed out the phrase "physical waveform" in this sentence from the "Other Notes" section of the DC_Offset description: "The Rx AMI_GetWave output waveform is the physical waveform at the Rx latch. It can have a non-zero DC component, which can be time-varying." Arpad asked if this sentence resolved any ambiguity, or if it needed to be written more clearly. Randy noted that this sentence had been taken to mean that there would be a small DC offset in many cases. Arpad suggested "physical waveform" should mean something you could measure in the lab with a probe. Walter said a voltage waveform had to be measured between two points, and the logical thing to do is measure relative to the latch. So, the waveform is measured between the signal and the reference at the latch, and the DC component would be quite small. The latch has a reference voltage that will determine whether the signal is considered high or low. If we were going to say the measurements are with respect to some local ground or rail, we would have to specify that location in order to say, "physical waveform". Arpad agreed with Walter, but asked what we would do if someone had a CMOS architecture, and there was no reference voltage, and everything was measured with respect to the ground or supply rails. Walter said in that case the model would return a non-zero NRZ_Threshold value. Walter said that in practice he didn't expect any model to add DC_Offset back in to the waveform it returned or to return a non-zero NRZ_Threshold. But if the model maker wants to return a waveform with a 1V DC offset and specify an NRZ_Threshold value of 1V, we won't prevent it. We won't prevent the model from doing it, but models probably won't do it anyway. Walter suggested that all we need to do is add a sentence explaining that NRZ_Threshold can be used in case a DC component is introduced somewhere in the system. Ambrish asked, regardless of the NRZ_Threshold value, if the EDA tool should shift the waveform for display if the model does not do anything with the DC_Offset. Walter said no, the EDA tool can display the waveform relative to the threshold (so DC offset would be zero - presumably the waveform as it was returned by GetWave()). Walter said the tool could also choose to add the DC_Offset back in when displaying the waveform. Ambrish asked how the tool would know whether the model had added in the DC offset to the waveform already. He noted that the tool could figure out if the waveform weren't centered around zero, but this didn't seem to be an ideal solution. Walter noted that the value of NRZ_Threshold returned by the model would be an indicator as to whether a non-zero DC offset had been added back in (if the NRZ_Threshold were on the order of mV it probably hasn't, if the NRZ_Threshold were .7V it probably has). Walter said he certainly didn't want to force the model maker to add the DC_Offset back in before returning the output waveform. Ambrish agreed but said we needed to add text to clarify the situation. Walter proposed stating that the model maker may choose to add DC_Offset to the output waveform, or they may not. Ambrish suggested the additional statement that if the DC_Offset is not added back in then the output should nominally be centered about zero. Ambrish noted that "nominally" is already used on page 207 of the spec. Arpad expressed concern that "NRZ_Threshold" might be abusing and overloading the term "threshold" when compared to existing IBIS uses such as the PAM4 thresholds. In a traditional differential case the threshold is a number compared to the difference waveform, but here NRZ_Threshold is supposed to return the VREFDQ reference level at the latch. In our existing differential flow the negative half of the signal would be the "threshold" according to this new NRZ_Threshold definition. Ambrish again noted that the BIRD had failed to address a relevant paragraph on page 207 in IBIS 7.0, which describes the wave argument to AMI_GetWave(). This statement on page 207 is directly affected by the BIRD: "The algorithmic model’s logic threshold may be non-zero, for example to model the differential offset of a receiver. However, that offset will usually be small compared to the input or output differential voltage." Ambrish noted that with this BIRD the offset might not be small, and this section should be modified. Walter proposed adding language to the section to state that, "if the offset is important, the model can specify it using NRZ_Threshold". Ambrish agreed in principle. Arpad asked who'd be willing to create another draft with the proposed language changes. Walter declined and said he did not think any of the changes were necessary. Ambrish took the AR to add a few clarifications. Arpad noted that his second question could be discussed at the next meeting, and we could move on to Randy's [C Comp Model] BIRD. Complex C_comp modeling: Randy reviewed some revised language with respect to K/T curve generation. He noted that he had replace references to K/T curve generation with the phrase "C_comp compensation algorithm". Arpad noted the sentence: "[C Comp Corner] values should represent the capacitance of the [C Comp Model] in Driving mode." and asked if [C Comp Corner] should only be required for Output models and not required for Input models. Randy noted that it wouldn't be much of a burden to the model maker to take a required C_comp value and put the same value into the three [C Comp Corner] entries, even for an Input. This would avoid cluttering up the spec with additional conditionals. Bob agreed and noted that if-this- then-that rules for required parameters could get confusing, and he noted that IBIS had tried to avoid this in the past. After some discussion, the group agreed that it was not an undue burden on the model maker to provide [C Comp Corner] any time [C Comp Model] is used. Walter noted that a model maker sophisticated enough to be using [C Comp Model] would be able to add [C Comp Corner]. Randy proposed adding a sentence explaining that [C Comp Corner] values may be ignored by EDA tools for a [C Comp Model] in Non-Driving mode. Randy then noted that he had removed this sentence: "The Param values shall all be numerical or all string values (or NA)." from the Corner format description. He noted that a previous sentence in the section had already made this clear. Randy noted that he had changed the language describing the rules of precedence, as discussed in the previous meeting. Mike L. asked Randy to review the BIRD to make sure it did not introduce any new parameters whose values were names as opposed to numbers. He noted that in IBIS 7.0 several new keywords contained names, and we had forgotten to specify the limits on their lengths. Randy noted that he would check, but he didn't think that was an issue with this BIRD. - Randy: Motion to adjourn. - Bob: Second. - Arpad: Thank you all for joining. AR: Ambrish to produce a draft of BIRD197.4 incorporating NRZ_Threshold and DC_Offset clarifications. AR: Randy to create a new [C Comp Model] BIRD draft incorporating the changes discussed in the meeting. ------------- Next meeting: 09 July 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives